We are hitting the exact failure mode this PR addresses in real team use on a current Buzz Desktop build.

Sanitized repro:

1. A managed coding agent is configured with parallelism=24.
2. Two unrelated top-level bug threads in the same channel mention that agent while the first turn is still active.
3. The harness startup state is agents=24 ... dedup=Queue meh=Steer.
4. For the later root, native steer reports ExpectedRunIdMissing and falls back to channel-scoped cancel-and-merge.
5. The agent completes the later bug but leaves the earlier bug without a result or blocker; when prompted later, it explicitly reports that the first investigation was displaced by the subsequent assignment.

We reproduced the same outcome with two independent bug roots sent nine seconds apart: only the second was picked up and shipped. The other 23 configured workers could not help because the in-flight boundary was the channel rather than the canonical root.

This makes thread scoping a correctness and throughput issue, not only a context-window improvement. A bug/intake channel naturally uses one top-level thread per independent task; users reasonably expect those roots to claim separate workers while replies within each root remain serialized and context-continuous.

The behavior proposed here—queue, cancellation, rotation, and session state keyed by conversation scope, with sibling roots executing concurrently—is exactly the contract we need. We would be happy to test a rebased version with a controlled three-root burst and verify:

• all three roots start on separate workers;
• each produces one thread-local callback;
• no prompt context crosses roots;
• no source ID or side effect is duplicated.

At present the operational choices are either serial assignment in the intake channel or splitting work into extra channels, both of which underuse the configured pool and undermine the thread model. A rebase/review of this PR would remove that workaround.

@skyerus The branch is now rebased onto current main (90e058eb) and updated at ad91e042.

The repair now uses one canonical NIP-10 parser across relay ingestion and ACP scoping, keys queue/in-flight/session ownership and invalidation by conversation scope, prevents cross-root context hydration, closes active/idle/future model-switch lifecycle holes, and carries thread-root identity through observer telemetry/UI correlation.

I also added a real-subprocess acceptance test for the burst you described: three simultaneous forum roots claim three fake ACP workers; same-root replies remain serialized to one owner/session; five source events produce exactly one prompt, callback, and terminal frame each; reactions/cleanup happen once; and no context crosses roots.

Would you be willing to run your controlled three-root burst against this head and report what you see?

Local verification on the final rebased commit:

• cargo test -p buzz-acp --locked: 687 passed, plus 9 lifecycle tests
• canonical thread parser: 6 passed
• desktop typecheck/check and focused observer/model tests: 119 passed
• workspace formatting/clippy, Sprig check, desktop/web/mobile checks: passed
• full just ci reaches unit tests and stops only on the unchanged buzz-db timestamp-precision assertion (replica_fence::tests::fence_starts_closed_and_opens_on_advance), which reproduces on clean origin/main